Providing Real World Contexts To Computer Applications

ABSTRACT

A method provides real world contexts to computer applications for outputting data describing one or more real world contexts. Components are identified in a computer application which implement instances of real world contexts and application components are updated so that a real world context instance is active during the execution by the application of a function for the real world context instance. Each real world context instance may have an instance identifier and is referenced by type of real world context.

BACKGROUND OF THE INVENTION

This invention relates to computer applications, and more particularly,to providing real world contexts for applications in a computer system.

The term “real world” is used herein to describe non-computer basedcontexts. A real world view of a process may be, for example, related toa business context. Real world context instances describe something thathas occurred which is of interest in the real world context. Forexample, a business context instance may describe an occurrence which isof interest to the business such as a new customer order arriving, aninvoice being paid, or a complaint being received from a customer. Realworld contexts may also include scientific experimental contexts,teaching or training related contexts, and other non-commerce relatedcontexts.

Real world context instances do not refer to computer or informationtechnology infrastructure. They are also not instances that necessarilyreflect errors in the computer system. They are therefore not the sameas more traditional “system events” which describe events that are goingon in the computer infrastructure and are used by computer or ITprofessionals.

Business models use terms that are familiar to business users todescribe how a computer system is operating. For various reasons, suchas performance and reliability, computer systems rarely provide astraightforward implementation of these business models. For example, asingle customer order may appear in a business model as a documentpassing between departments. However, in the computer system, it maybegin as a JMS (Java™ Message Service, Java is a trade mark of SunMicrosystems, Inc. in the United States, other countries or both) orIBM® WebSphere® MQ (IBM and WebSphere are trademarks of InternationalBusiness Machines Corporation in the United States, other countries orboth) message, morph into a BPEL (Business Process Execution Language)process and end up as a number of database records dispersed throughoutthe computer system.

Over time, the connection between the application and the business modelis lost, making it difficult to relate between the real world and theprocessing of the computer system. This affects the quality of usermessages and other information generated by the computer system. It alsomakes it harder to understand the significance of failures in thecomputer system to the business.

Often a collection of records of business instances is needed to analyzea particular aspect of a business such as a historical trend or astatistical average. These records may be written over a period of timeand consequently are interleaved with other, unrelated, records in thedata stores.

The most efficient way to retrieve a collection of related businessrecords is to classify them appropriately as they are written to thedata stores. This classification is recorded in a particular field ineach record. For example, if records contained a field for the day ofthe week that the record was written (“Sunday”, “Monday”, “Tuesday”,“Wednesday”, “Thursday”, “Friday” or “Saturday”) it would be simple toretrieve all records generated on, say, any Monday.

However, it is unlikely that any one classification scheme will satisfythe information needs of all users. For example, one person may need toview records describing the activities of a particular user whileanother person may wish to view the history of all updates made to aparticular object during a particular day, irrespective of who made theupdate.

BRIEF SUMMARY OF THE INVENTION

According to one aspect of the present invention, a method provides realworld contexts to computer applications for outputting data describingone or more real world contexts. The method comprises identifyingcomponents in a computer application which implement instances of realworld contexts and updating application components so that a real worldcontext instance is active during the execution by the application of afunction for the real world context instance. Each real world contextinstance may have an instance identifier and is referenced by type ofreal world context.

According to another aspect of the present invention, a computer programproduct on a computer system for providing real world contexts tocomputer applications for outputting data describing one or more realworld contexts comprises a computer readable medium having computerreadable program code embodied therein. The computer readable programcode comprises computer readable program code configured to updateapplication components in an application so that a real world contextinstance is active during the execution by the application of a functionfor the real world context instance. Each real world context instancemay have an instance identifier and is referenced by a type of realworld context.

According to yet another aspect of the present invention, a system forproviding real world contexts to computer applications for outputtingdata describing one or more real world contexts comprises means foridentifying components in a computer application which implementinstances of real world contexts and means for updating applicationcomponents so that a real world context instance is active during theexecution by the application of a function for the real world contextinstance. Each real world context instance may have an instanceidentifier and may be referenced by type of real world context.

Other aspects and features of the present invention, as defined solelyby the claims, will become apparent to those ordinarily skilled in theart upon review of the following non-limited detailed description of theinvention in conjunction with the accompanying figures.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a diagram of a real world model in the form of a businessmodel in accordance with an aspect of the present invention;

FIG. 2 is a business context instance in accordance with an aspect ofthe present invention;

FIG. 3 is a class diagram in accordance with an aspect of the presentinvention; and

FIG. 4 is a block diagram in accordance with an aspect of the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

As will be appreciated by one of skill in the art, the present inventionmay be embodied as a method, system, or computer program product.Accordingly, the present invention may take the form of an entirelyhardware embodiment, an entirely software embodiment (includingfirmware, resident software, micro-code, etc.) or an embodimentcombining software and hardware aspects all generally referred to hereinas a “circuit” or “module.” Furthermore, the present invention may takethe form of a computer program product on a computer-usable storagemedium having computer-usable program code embodied in the medium.

Any suitable computer readable medium may be utilized. Thecomputer-usable or computer-readable medium may be, for example but notlimited to, an electronic, magnetic, optical, electromagnetic, infrared,or semiconductor system, apparatus, device, or propagation medium. Morespecific examples (a nonexhaustive list) of the computer-readable mediumwould include the following: an electrical connection having one or morewires, a portable computer diskette, a hard disk, a random access memory(RAM), a read-only memory (ROM), an erasable programmable read-onlymemory (EPROM or Flash memory), an optical fiber, a portable compactdisc read-only memory (CD-ROM), an optical storage device, atransmission media such as those supporting the Internet or an intranet,or a magnetic storage device. Note that the computer-usable orcomputer-readable medium could even be paper or another suitable mediumupon which the program is printed, as the program can be electronicallycaptured, via, for instance, optical scanning of the paper or othermedium, then compiled, interpreted, or otherwise processed in a suitablemanner, if necessary, and then stored in a computer memory. In thecontext of this document, a computer-usable or computer-readable mediummay be any medium that can contain, store, communicate, propagate, ortransport the program for use by or in connection with the instructionexecution system, apparatus, or device.

Computer program code for carrying out operations of the presentinvention may be written in an object oriented programming language suchas Java7, Smalltalk or C++. However, the computer program code forcarrying out operations of the present invention may also be written inconventional procedural programming languages, such as the “C”programming language. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer. In the latter scenario, theremote computer may be connected to the user's computer through a localarea network (LAN) or a wide area network (WAN), or the connection maybe made to an external computer (for example, through the Internet usingan Internet Service Provider).

The present invention is described below with reference to flowchartillustrations and/or block diagrams of methods, apparatus (systems) andcomputer program products according to embodiments of the invention. Itwill be understood that each block of the flowchart illustrations and/orblock diagrams, and combinations of blocks in the flowchartillustrations and/or block diagrams, can be implemented by computerprogram instructions. These computer program instructions may beprovided to a processor of a general purpose computer, special purposecomputer, or other programmable data processing apparatus to produce amachine, such that the instructions, which execute via the processor ofthe computer or other programmable data processing apparatus, createmeans for implementing the functions/acts specified in the flowchartand/or block diagram block or blocks.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

Real world context instances will be described by business contexts asthis illustrates the issues that business professionals have when usinga computer system applied in a business environment. A conceptualmapping middleware may be provided and applied to a computer system toprovide information to enable a non-computer user to know where they arein a real world model, such as a business model. Data may be added to acomputer implementation to describe application data in a real worldcontext. The data is passed around the computer system with data addedas instances of real world contexts happen. The data is availabledescribing the instance of a real world context.

An aspect of the present invention will be described in terms of abusiness user's model. The described business user's model has fourconcepts which defines types of business context instances. While thedefined types of business context instances have been chosen as theyappear repeatedly in the many different types of business models, itwill be appreciated by those skilled in the art that other types ofcontext instances may be chosen to suit a particular real world model.

A business solution may describe all of the processing performed by acomputer system to support a significant part of the business, e.g.,order processing. In an application server environment, such as IBMWebSphere Application Server, a solution may include a number of J2EE(Java 2 Platform, Enterprise Edition) applications. Solutions may shareJ2EE applications.

In addition, there are three more fine-grained concepts:

-   The business task which describes the processing to complete a small    independent piece of work, e.g., the processing of a single customer    order.-   The business conversation which is the processing performed on    behalf of a single person or business partner over a particular    period, e.g., the requests made by a single warehouse worker during    a single day.-   The business data which describes the processing that affects a    particular collection or instance of some business data, e.g., a    single stock item record.

In a typical computer system, each of these concepts is implemented byone or more components. FIG. 1 is an example of a business model thatshows a business process 100 which is part of an order processingsolution. The overall task being performed is represented by a sequenceof activities 101, 102, 103, 104, 105, 106, 107. The work of each typeof user 110, 111, 112 is shown in a horizontal “swim lane.” For example,the job that a warehouse worker (user 111) performs is shown in themiddle lane. Along the bottom of FIG. 1 are the data objects 120, 121,122 that are being updated.

FIG. 1 shows an update to the stock item records 121 to reflect thegoods that the customer ordered. During the activity “Update Stock” 102,all four of the business concepts intersect. However, during the overallprocessing of the computer system, the concepts change independently ofone another. At any one time there are many instances of this businessprocess 100 executing in the computer system, involving many peopleperforming the three roles identified 110, 111, 112.

Each business context instance may have a type (for example, businesssolution, business conversation, business task or business data), aninstance identifier and an optional set of name-value pair properties.The business context instances may be associated with the thread so theyare available to all components processing a particular request. Thesecomponents may update and change them at any time.

FIG. 2 shows a business context instance 200. The business contextinstance has a type 201, an instance identifier 202, and optionalproperties 203. As an example of the benefits of the described system,each of the automated steps in the overall model may produce an eventrecord. Each event record has identifiers of one or more contextinstances stored inside it, for example, an event record may haveidentifiers of a solution context instance, a task context instance, aconversation context instance and a data context instance. Informationabout different aspects of a business process can then be queried asfollows:

The event records that relate to the processing of an individual orderwould be classified by the task context identifier.

The event records relating to all of the processes that an individualwarehouse worker has been involved with would be classified by theconversation context identifier.

The orders that requested a particular item of stock would be classifiedby the data context identifier.

Since the business contexts represent concepts in the business model, itmay be desirable to record details about them. Each instance of abusiness context may, optionally, have a description in the form of aset of properties written to the data stores. This can be written at anytime. The business context description identifies the component it isassociated with (if any) and its relationship to the business model. Theidentifier of the business context description is the same as thebusiness context instance's unique identifier.

An aspect of the present invention will be described with respect to anapplication on IBM WebSphere Application Server:

1. Work through the business model, or high-level design, and identifythe key concepts that are relevant to the application's users. Inparticular, identify the key user roles, the business tasks that thecomputer system performs and the key data entities that the businessowns. The example shown in FIG. 1 has the following business concepts:Customer, Warehouse Worker, Accounts Clerk, Fulfil Order Process, Order,Stock, Invoices.

2. Group the business concepts into related types. These groupings willform the basis of the business context types. The business context typesmay be, for example, the types of solution, task, conversation and datadescribed above in relation to FIG. 1, or alternatively, they may beother defined types. User roles/ conversations Business Tasks BusinessEntities/Data Customer Fulfil Order Order Process Warehouse Worker StockAccounts Clerk Invoices

3. For each business concept, decide on what the life span of aninstance is and how each instance is identified. For example, if thereis a business task to “fulfil an order” then there could be a newbusiness task context instance for every order. The order identifiercould be the context instance identifier.

4. Review the design of the WebSphere Application Server application(s)to identify which component (or method on a component) implements eachof the business concepts identified. Typically, servlets, JSPs (JavaService Pages) and portlets represent the user roles, session beansand/or BPEL processes represent the business tasks and entity beansrepresent business entities.

5. Use either the Java programming interface or a deployment descriptorform to update the application components so that a context instance isactive while the application executes the function for an instance of abusiness concept.

FIG. 3 is a simplified class diagram showing a java programming API fora service in accordance with an aspect of the present invention. Anobject in the form of a controller interface 302 referred to as theBusinessContextController. This controller interface 302 manages thedata for a single business context type 303 and its association with thecurrent thread. This includes the instance identifier 304 and acollection of properties 305 held in a BusinessContextProperties object306. An interface 308 referred to as the BusinessContextFactory createsa BusinessContextController object 302. The BusinessContextFactory 308can also return the types 303 of business contexts active on the threadand create an event mediator 310 capable of adding details of the activebusiness contexts to a Common Base Event 312.

The Event Infrastructure of WebSphere Messaging Service provides theability to record significant events that happen in the processing ofbusiness requests. Provided a WebSphere event factory is used, the eventinfrastructure automatically copies the business contexts associatedwith the current thread into each event it creates. The code snippetbelow shows how to extract the BusinessContextController 302 for abusiness task from the current thread and then add some properties toit:

-   import com.ibm.websphere.bcds.*; import javax.naming.Context; String    factoryName=“java:comp/websphere/bcds/factory”;-   String contextType=BusinessContextType.BUSINESS_TASK.getContextType(    );-   Context ctx=new InitialContext( );-   BusinessContextFactory    factory=BusinessContextFactory)ctx.lookup(factoryName);-   BusinessContextController bcc=factory.getController(contextType);-   BusinessContextProperties properties=bcc.getpropertieso;-   bcc.setContextid(“NewOrder-O56232030516”);-   properties.setProperty(“customerNo, “C03738927”);-   properties.setProperty(“orderNo”, “056232-2003-May”);-   properties.setProperty(“orderValue”, “1394000”);

This is how to clear an instance of a business context from the threadbcc.clearContextid( ). The thread maintains a stack of context instancesfor each context type. Consequently, when clearContextid( ) is called,it restores the context instance for this context type that was on thethread when setContextid( ) was called.

Business contexts are controlled through extended deployment descriptorsin an application server. In the described aspect, the server is aWebSphere Application Server. The deployment descriptors can associatean instance of a business context with a HTTP (HyperText TransferProtocol) request, a HTTP session, a method on an Enterprise JavaBean(EJB) or the entire lifecycle of an entity bean.

FIG. 4 shows a method request 401 on an EJB 405. An Object RequestBroker (ORB) 402 receives a request from a method 401 which is passed toan EJB container 403. The container 403 identifies the type of objectrequest and calls the pre-invocation collaborators that are registeredfor that object. If the Business Context Data Service (BCDS)collaborator 404 is registered, the Business Context Data Service 407 iscalled, and establishes the business context on the thread. Once the EJBmethod 406 has completed, the post-invocation collaborator 405 is calledto remove the context. It is also possible to create events with thecontext instance identifiers specified explicitly on the call ratherthan relying on the context being associated with the thread.

The application can control the values used as context identifiers. Thismeans they can be based on values from the application data, making iteasier to set up the context identifiers when requests are imported fromoutside the WebSphere environment.

The example below shows the extended deployment descriptor forcontrolling business contexts. It is associated with an EJB method andindicates that the method represents the scope of a business context. Anew instance of the business context is started each time the method iscalled. <businessContextData contextType=“BusinessTask”method=“createOrder”>  <contextId fixedValue=“ORDER”parameter=“orderNumber” timestamp=“no” delimiter=“:”/>  <contextProperty name=“usageScenario”  fixedValue=“NewOrder-v1.34”/>  <contextProperty name=“customerNo”  parameter=“customerNumber”/> </businessContextData>

When the method returns, the context is cleared from the thread.

The attributes and elements are as follows:

-   businessContextData—This is the outer element for the deployment    descriptor. It has the following mandatory attributes:-   contextType—This is a mandatory attribute and has a string value.    This identifies the type of the business context.-   method—This is a mandatory attribute and has a string value. This    identifies the method name that the context is to be attached to.

The following are optional elements:

-   contextid—There may be between 0-1 occurrences of this element. It    has the following optional attributes that define how the contextid    value is built up: fixedValue, parameter, timestamp and delimiter.    The timestamp is used if the contextid element is omitted.-   fixedValue—This is an optional attribute that specifies a fixed    string value.-   parameter—This is an optional attribute that specifies that the    string value from this method parameter should be used as one of the    values for the element.-   timestamp—This is an optional attribute that specifies that the    current time should be included in the contextid. The default-value    of timestamp=“no” is used if this attribute is omitted.-   delimiter—This is an optional attribute that specifies a character    that is used to separate the values specified in the other    attributes. No delimiter is used if this attribute is omitted.-   contextProperty—There may be 0-n occurances of this element. It has    the following attributes:-   name—This is a mandatory attribute that defines the name of the    property.-   fixedValue—This is an optional attribute that specifies a fixed    string value.-   parameter—This is an optional attribute that specifies that the    string value from this method parameter should be used as the value    for the element.-   timestamp—This is an optional attribute that specifies that the    current time should be included in the property value. The    default-value of timestamp=“no” is used if this attribute is    omitted.-   delimiter—This is an optional attribute that specifies a character    that is used to separate the values specified in the other    attributes. No delimiter is used if this attribute is omitted.

Each contextProperty may have a different “name” value.

The business context instances associated with the current thread areautomatically transported from one WebSphere server to another as callspass directly between EJBs. However, there is no such automaticmechanism for JMS. If a business context instance needs to pass acrossJMS in an application message, the active contexts and their propertiesare formatted into an XML document and sent as a JMS header property.

The XML below illustrates a format of an XML document used to import andexport business contexts from a WebSphere server. This XML is typicallyused to transport the business contexts over JMS in thecom.ibm.websphere.bcds.BusinessContexts property.<WebSphereBusinessContexts>  <context typeName=“businessSolution”id=“Order Processing”/>  <context typeName=“businessConversation”id=“JGB-030516”>   <property name=“startTime” value=“09:00”/>  <property name=“operator” value=“Joe G Bloggs”/>  </context>  <contexttypeName=“businessTask” id=“NewOrder-O56232030516”>   <propertyname=“customerNo” value=“C03738927”/>   <property name=“orderNo”values=“O56232-2003-May”/>   <property name=“orderValue”value=“1394000”/>  </context> <context typeName=“businessData”id=“Invoice-134252-030516”>   <property name=“creationTime”value=“2003-05-09T14:41:45.921000-05:00”/>  </context></WebSphereBusinessContext>

Business context data relates the processing of the application to thebusiness it is supporting. Consequently, applications are better placedto output diagnostics, events and messages that make sense to thebusiness user.

The present invention may be implemented as a computer program product,comprising a set of program instructions for controlling a computer orsimilar device. These instructions can be supplied preloaded into asystem or recorded on a storage medium such as a CD-ROM, or madeavailable for down loading over a network such as the Internet or amobile telephone network.

The described method and apparatus is concerned with the composition ofindividual manageable resources into solutions, and how the runtimesolutions can be managed. However, the same concepts could be applied atany level of the stack where an aggregate or group resource is composedof multiple individual resources for the purposes of management. Forexample, for managing server clusters.

The description provided above in relation to FIGS. 1 to 3 relates tohow components of a solution can be installed. The description providedin relation to FIGS. 4 to 7 describes how solutions can be packaged fordeployment and subsequent change management. This method differs in thatit applies to the runtime management of a solution and how to monitorand administer the various runtime components of a solution. Thesolution may or may not have been installed via the mechanism describedabove in relation to FIGS. 1 to 7.

Referring to FIG. 8, a solution module as described in relation to FIG.4 may be used to instantiate manageable resources which may be part of a“solution instance”. Two forms of solution module 801 are shown in FIG.8 which package the software components 802 of a solution. The softwarecomponents 802 create the manageable units 803 for each instance of thesolution.

A “solution instance” 804 is defined as a manageable resource thatfederates others together, and represents a higher-level entity that auser wants to monitor and control (for example, controls such as start,stop). Both solution modules 801 and solution instances 804 may be usedat various levels of the software stack.

For example, a solution module may be used to create a “solutionplatform” 805, which may be a combination of a database 806, anapplication server 807, and a directory 808 configured together toperform as an e-business server. As a second example, a solutioninstance may be used to describe the application components 810 thatprovide one of the “solutions” 809 running on that solution platform805.

Referring to FIG. 9, an illustration is provided of how a solutioninstance 804 may be used to give administrators a solution-level view onthe IT system. In this example, a purchasing solution 901 is composed ofa buyer application 902 running on a WebSphere Application Server 903; abuyer database 904 running in a IBM DB2® database 905; and a set ofchannels and processes 906 running on a B2B Gateway (DB2 is a trademarkof International Business Machines Corporation in the United States,other countries, or both).

The administrator can see that the purchasing solution 901 has anoverall status of “yellow” (shown as diagonal hatching) 907. The buyerapplication 902 and the buyer database 904 are operating normally asshown in “green” (shown as vertical hatching) 916. The B2B processes 906are not operating and have a status of “red” (shown as checked hatching)908. This results in an overall status of “yellow” for the purchasingsolution 901 as the function of the overall solution is degraded but notcompletely stopped. If the buyer application 902 or the buyer database904 were not operating, the overall solution status would be “red”.

It can be seen from FIG. 9, that status propagation 910 is up thecomponent levels. Status propagation is one of the purposes of defininga solution instance. Another purpose is to support solution-leveloperations such as starting or stopping an entire solution. FIG. 9illustrates that there are operations 912 (e.g. start, stop) that may beavailable at the level of a solution 913 or on individual solutioncomponents 914. There are other, additional operations 915 (e.g. viewlogs, configure) that may only be available on individual components914.

The key part of this description relates to how the information requiredto define and manage a solution instance is established in the runtimesystem, without requiring the writing of code for each solutioninstance. The concept is that a “solution specification sheet” (SSS) isdefined when the solution is developed. This solution specificationsheet contains the information which describes the components of thesolution, the relationships between them, and the rules or constraintswhich determine how they should be managed. However, the solutionspecification sheet (like the solution module) is independent of anyparticular physical instantiation of the solution instance. Instead, itmay be used either as part of the deployment process, or via a processof assisted discovery, to create a runtime representation of thesolution instance which allows it to be managed.

FIG. 10 illustrates how a solution specification sheet 1000 can be usedas part of the deployment process to create a manageable solutioninstance. In the example shown in this diagram, solution tooling 1002 isused to create the artifacts 1001 in a solution, including:

-   An EAR file 1004 which contains a J2EE catalog application 1005;-   A queue definition file 1006 which contains the definition of a    queue 1007 to be used for orders;-   A DDL (data definition language) file 1008 which contains the    definition of the catalog database 1009.

These artifacts 1001 are packaged and defined in a solution module 1010.The solution tooling 1002 is also used to construct a solutionspecification sheet 1000, which describes the J2EE application 1005,queue 1007 and database 1009 and how the catalog solution (MySoln) 1014federates 1012 these together. Although the example shows a one to onecorrespondence between artefacts 1001 in the solution module andcomponents 1005, 1007, 1009 of a solution instance, this is notrequired. One artifact may cause the instantiation of multiplemanageable resources. Furthermore, not all of those resources may bepart of the solution instance. A solution instance may federateresources that are created by multiple solution modules or by othermeans.

During deployment, the artifacts 1001 in the solution module 1010 aretargeted at and deployed to their receiving hosting environments. Inthis example, namely a WAS server 1015 for the EAR file 1004, an MQserver 1017 for the queue definition 1006, and a DB2 instance 1019 forthe DDL file 1008.

The solution specification sheet 1000 is also targeted at a receivingenvironment that is capable of interpreting it. This environment hasbeen called a “solution hosting environment” (SHE) 1024. As well asreceiving the solution specification sheet 1000, the solution hostingenvironment 1024 also receives the list of target hosting environmentsfrom the deployment, and it uses this information in conjunction withthe solution specification sheet 1000 to establish the identity of thecomponents that are part of the solution instance. The solutionspecification sheet 1000 is deployed after the other solution artifacts1001, so that the solution hosting environment 1024 can use theinformation provided to it to go out and automatically discover themanageable resource instances in the target hosting environments.

A similar process may be used for existing solutions, or ones which arenot deployed using a solution module. In this case, instead of thedeployment application constructing the list of target hostingenvironments that the solution hosting environment can use to discoverthe resource instances, this information must be provided by anothermeans. One approach would be for the user to enter the list of hostingenvironments. Another would be to use information in the solutionspecification sheet to identify candidate hosting environments bysearching in a registry or some other source of information, and thenallowing a user to identify the actual hosting environments.

FIG. 11 illustrates a solution specification sheet 1000 in more detail.The sheet 1000 includes the following:

-   An identity of the solution instance 1101;-   A set of target hosting environments 1102 relevant to the solution    instance definition;-   A set of components 1103 relevant to the solution instance    definition; and-   Solution characteristics 1104, such as relationships between the    components.

In FIG. 11, a solution module definition 1105 as described in FIGS. 4and 5 is shown which defines the artifacts 1001 of the solution module1010 and the solution specification sheet 1000. The logical targets 1106of the artifacts 1101 are defined and passed 1107 as parameters 1102 tothe target solution hosting environment 1024 of the solutionspecification sheet 1000.

FIG. 11 shows how the logical targets 1106 defined in the solutionmodule definition 1105 and whose runtime relationships are defined inthe solution specification sheet 1000 map to the hosting environments1015, 1017 of the artifacts 1005, 1007 and the solution hostingenvironment 1024 of the solution instance 1014 which federates 1012together components 1005, 1007 with the hosting environments 1015, 1017.

Important characteristics of the solution specification sheet 1000include the following:

-   The logical targets may map to multiple physical targets;-   The logical components are described by defining the requirements on    the components (e.g. their type, name or other characteristics,    including required relationships to other components, such as the    host's relationships in FIG. 10);-   Each logical component may map to multiple physical components;-   The solution definition asserts the existence of relationships that    define the solution instance and should be used to manage it (e.g.    the federate relationships in FIG. 10). It may also assert    additional information about the solution dependencies and how the    solution should be managed, for example to identify which components    should be stopped or started when the solution is stopped or    started, and in what order; or to indicate how status should be    propagated.

FIG. 12 illustrates one possible implementation of a solution hostingenvironment 1024 that can interpret a solution specification sheet 1000.The solution specification sheet 1000 is “installed” into the solutionhosting environment 1024 using a standard operation, as part of thenormal deployment process.

In this specific example, these operations are provided through a“touchpoint webservice” (TPWS) 1201. Installing the solutionspecification sheet 1000 causes the instantiation of a data object 1202representing a solution instance within the solution hosting environment1024. This data object 1202 includes a model 1203 of the manageableresource instances that comprise the solution.

For managing the solution instances 1202, the solution hostingenvironment 1024 exposes a set of standard operations 1204, for example,start, stop, getstatus. These operations 1204 can be applied to anysolution instance 1202. The standard operations 1204 are providedthrough a TPWS 1206.

To implement these operations 1204, the solution hosting environment1024 makes use of:

-   The manageable resource model 1203 that corresponds to the specific    solution instance 1202;-   Policy information 1205 that determines how operations 1204 should    be applied; and-   Optionally, executable or interpretable definitions (e.g. Code    plugins or rules) which may have been provided for a specific    solution instance 1207.

The above description shows how the runtime components of a computersolution can be described by a developer of a solution and managed by auser of the solution. The solution specification sheet provides adescription of the components of the solution and theirinterrelationships. A solution hosting environment hosts the solutionspecification sheet and federates the resources used by the componentsdescribed in the solution specification sheet. The solutionspecification sheet is used to describe a solution instance which can bedisplayed to a user as shown in FIG. 9 enabling management of thecomponents of the solution.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems which perform the specified functions or acts, or combinationsof special purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The description of the present invention has been presented for purposesof illustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the art. Theembodiment was chosen and described in order to best explain theprinciples of the invention, the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

1. A method for providing real world contexts to computer applicationsfor outputting data describing one or more real world contexts, themethod comprising: identifying components in a computer applicationwhich implement instances of real world contexts; and updatingapplication components so that a real world context instance is activeduring the execution by the application of a function for the real worldcontext instance; wherein each real world context instance has aninstance identifier and is referenced by type of real world context. 2.The method as claimed in claim 1, wherein the real world contextscomprise at least one of business contexts, experimental contexts andother non-computer system implementation contexts.
 3. The method asclaimed in claim 2, wherein the real world contexts comprise businesscontexts and the business context comprise at least one of a solutioncontext, a task context, a role context and a data context.
 4. Themethod as claimed in claim 3, wherein the business context of a solutioncontext groups context instances that relate to processing performed bythe application to support a unit of the business.
 5. The method asclaimed in claim 3, wherein the business context of a task contextgroups context instances that relate to work undertaken to complete atask in a business.
 6. The method as claimed in claim 3, wherein abusiness context of a role context groups context instances that relateto the processing in the application performed on behalf of a user in agiven period.
 7. The method as claimed in claim 3, wherein the businesscontext of a data context groups context instances that relate toprocessing by the application of a data item that represents an instanceof entity, object, data record or collection of data.
 8. The method asclaimed in claim 1, wherein the real world context instance comprisesproperties describing the instance.
 9. The method as claimed in claim 1,wherein updating application components so that a real world contextinstance is active during the execution by the application of a functionfor the real world context instance comprises controlling the real worldcontext instances by defining extended deployment descriptors in anapplication server.
 10. The method as claimed in claim 1, whereinupdating application components so that a real world context instance isactive during the execution by the application of a function for thereal world context instance comprises controlling the real world contextinstances by managing data for real world context instances andassociating context types with a current application thread.
 11. Acomputer program product on a computer system for providing real worldcontexts to computer applications for outputting data describing one ormore real world contexts, the computer program product comprising: acomputer readable medium having computer readable program code embodiedtherein, the computer readable program code comprising: computerreadable program code configured to update application components in anapplication so that a real world context instance is active during theexecution by the application of a function for the real world contextinstance; wherein each real world context instance has an instanceidentifier and is referenced by a type of real world context.
 12. Thecomputer program product as claimed in claim 11, wherein the real worldcontexts comprise at least one of business contexts, experimentalcontexts and other non-computer system implementation contexts.
 13. Thecomputer program product as claimed in claim 12, wherein the real worldcontexts comprises business contexts and the types of business contextcomprise at least one of a solution context, a task context, a rolecontext and a data context.
 14. The computer program product as claimedin claim 13, wherein the business context of a solution context isrepresented by at least one J2EE (Java 2 Platform, Enterprise Edition)application.
 15. The computer program product as claimed in claim 13,wherein the business context of a task context is represented by atleast one of a session bean and Business Process Execution Language(BPEL) process.
 16. The computer program product as claimed in claim 13,wherein the business context of a role context is represented by atleast one of a servlet, Java Service Page (JSP), and portlet.
 17. Thecomputer program product as claimed in claim 13, wherein the businesscontext of a data context is represented by at least one entity bean.18. The computer program product as claimed in claim 11, wherein thereal world context instance comprises properties describing the instancein the form of string name-value pairs defined by the application. 19.The computer program product as claimed in claim 11, wherein thecomputer readable program code configured to update applicationcomponents comprises computer readable program code configured tocontrol the real world context instances by extended deploymentdescriptors in an application server.
 20. The computer program productas claimed in claim 19, wherein the application server is an IBMWebSphere Application Server.
 21. The computer program product asclaimed in claim 11, wherein the computer readable program codeconfigured to update application components comprises computer readableprogram code configured to control the real world context instances bymanaging data for real world context instances and associating contexttypes with a current application thread.
 22. The computer programproduct as claimed in claim 21, wherein the computer readable programcode configured to control the real world context instances by managingdata for real world context instances and associating context types witha current application thread is a java programming interface.
 23. Asystem for providing real world contexts to computer applications foroutputting data describing one or more real world contexts, the systemcomprising: means for identifying components in a computer applicationwhich implement instances of real world contexts; and means for updatingapplication components so that a real world context instance is activeduring the execution by the application of a function for the real worldcontext instance; wherein each real world context instance has aninstance identifier and is referenced by type of real world context.